Skip to content

Conversation

tropicaaal
Copy link
Contributor

@tropicaaal tropicaaal commented Oct 11, 2025

This PR provides a more "proper" implementation of process exiting in VEXos programs by going through vexSystemExitRequest rather than calling intrinsics::abort, which exits using an undefined instruction trap. This matches the existing implementation of rt::abort_internal and therefore makes std::process::exit have the same behavior as returning from main on VEXos targets.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Oct 11, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 11, 2025

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@joboet
Copy link
Member

joboet commented Oct 13, 2025

Given that vexSystemExitRequest doesn't give an indication of the exit reason should abort result in a trap? Otherwise r=me

@bors delegate+
r? joboet

@bors
Copy link
Collaborator

bors commented Oct 13, 2025

✌️ @tropicaaal, you can now approve this pull request!

If @joboet told you to "r=me" after making some further change, please make that change, then do @bors r=@joboet

@tropicaaal
Copy link
Contributor Author

tropicaaal commented Oct 13, 2025

Given that vexSystemExitRequest doesn't give an indication of the exit reason should abort result in a trap?

I don't think it should; the default behavior of a trap on this target will result in the user processor hanging with an undefined instruction exception being shown on screen, which requires the user to manually stop the program and is likely to mislead someone into thinking that their program exhibits UB. I think that regardless of exit reason (which the OS has no facility to report unless we print it out ourselves before exiting) going through the proper method of killing the program is always a better option than trapping for both abort and exit.

@tropicaaal
Copy link
Contributor Author

tropicaaal commented Oct 13, 2025

unless there's anything further I should do (e.g. having the libstd runtime report the error code in some way), I think this should be fine, or at least an improvement over the previous behavior regardless.

@bors r=@joboet

@bors
Copy link
Collaborator

bors commented Oct 13, 2025

📌 Commit 04da682 has been approved by joboet

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 13, 2025
chenyukang added a commit to chenyukang/rust that referenced this pull request Oct 14, 2025
std: implement `pal::os::exit` for VEXos

This PR provides a more "proper" implementation of process exiting in VEXos programs by going through `vexSystemExitRequest` rather than calling `intrinsics::abort`, which exits using an undefined instruction trap. This matches the existing implementation of `rt::abort_internal` and therefore makes `std::process::exit` have the same behavior as returning from main on VEXos targets.
Zalathar added a commit to Zalathar/rust that referenced this pull request Oct 14, 2025
std: implement `pal::os::exit` for VEXos

This PR provides a more "proper" implementation of process exiting in VEXos programs by going through `vexSystemExitRequest` rather than calling `intrinsics::abort`, which exits using an undefined instruction trap. This matches the existing implementation of `rt::abort_internal` and therefore makes `std::process::exit` have the same behavior as returning from main on VEXos targets.
Zalathar added a commit to Zalathar/rust that referenced this pull request Oct 14, 2025
std: implement `pal::os::exit` for VEXos

This PR provides a more "proper" implementation of process exiting in VEXos programs by going through `vexSystemExitRequest` rather than calling `intrinsics::abort`, which exits using an undefined instruction trap. This matches the existing implementation of `rt::abort_internal` and therefore makes `std::process::exit` have the same behavior as returning from main on VEXos targets.
bors added a commit that referenced this pull request Oct 14, 2025
Rollup of 11 pull requests

Successful merges:

 - #146277 (Enable `u64` limbs in `core::num::bignum`)
 - #146976 (constify basic Clone impls)
 - #147249 (Do two passes of `handle_opaque_type_uses_next`)
 - #147266 (fix 2 search graph bugs)
 - #147468 (Implement fs api set_times and set_times_nofollow)
 - #147497 (`proc_macro` cleanups (3/N))
 - #147594 (std: implement `pal::os::exit` for VEXos)
 - #147596 (Adjust the Arm targets in CI to reflect latest changes)
 - #147607 (GVN: Invalidate derefs at loop headers)
 - #147620 (Avoid redundant UB check in RangeFrom slice indexing)
 - #147647 (Hide vendoring and copyright in GHA group)

r? `@ghost`
`@rustbot` modify labels: rollup
Zalathar added a commit to Zalathar/rust that referenced this pull request Oct 14, 2025
std: implement `pal::os::exit` for VEXos

This PR provides a more "proper" implementation of process exiting in VEXos programs by going through `vexSystemExitRequest` rather than calling `intrinsics::abort`, which exits using an undefined instruction trap. This matches the existing implementation of `rt::abort_internal` and therefore makes `std::process::exit` have the same behavior as returning from main on VEXos targets.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 14, 2025
std: implement `pal::os::exit` for VEXos

This PR provides a more "proper" implementation of process exiting in VEXos programs by going through `vexSystemExitRequest` rather than calling `intrinsics::abort`, which exits using an undefined instruction trap. This matches the existing implementation of `rt::abort_internal` and therefore makes `std::process::exit` have the same behavior as returning from main on VEXos targets.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants